The eight fallacies of distributed computing are commonly referenced when discussing distributed computing. The fallacies are as follows: the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology does not change, there is a single administrator, transport cost is zero and the network is homogeneous.
Engineers carefully consider these fallacies when creating any distributed computing system, and engineers typically account for the fallacies in any system design. In most distributed computing systems, a central operating system controls the system. In such a model, the central operating system can coordinate all of the aspects of the system.
Controller Area Networking, or CAN, is a networking standard used primarily in the automotive industry. Bosch Automotive invented CAN in 1986 as a way for automotive ECUs to communicate with each other. The standard saw increasing use through the 1990s and is now on every vehicle on the road today throughout the world. Some industrial applications also use CAN, but the automotive industry remains the primary user of CAN.
The CAN bus is comprised of a single twisted pair of wires that connect all ECUs on the network together. There is no router or other controller necessary other than the CAN controller on each ECU attached to the network. The unique priority/identifier field in every CAN message provides not just a priority in a software sense, but high priority messages also overwrite lower priority messages electrically, grounding out the lower priority signals.
A CAN message is comprised of several parts: an arbitration field, a control field, a data field, a CRC field, and an end of frame field. The arbitration field is comprised of the CAN identifier bit string, which doubles as the message priority. From there, the control field exists to tell other ECUs how large the data field will be. The data field can consist of 1 to 8 bytes (8 and 64 bits) of information. Finally, the CRC field and End of Frame fields provide data integrity and notification to the bus that the message is complete.
The arbitration field is fixed for a particular message. Each message has a unique identifier, though multiple of the same messages may be sent over CAN. Typically, a CAN Database, or DBC, file stores definitions of all messages for a particular bus. All ECUs on the network have access to the DBC file for decoding any and all incoming messages. Messages may not have their identifiers changed at random to protect the integrity of the system.
The data field is only 8 bytes, significantly smaller than most networking systems. This makes it difficult to send anything more than a short string or characters or a single large number. Typically, CAN messages are broken down further into signals, which have defined values and bit locations within a message. This data is typically stored in the DBC file.
Automobiles typically have dozens of ECUs in various locations throughout the vehicle. Typically, each ECU handles a specific set of functions. For example, an Engine Control Module controls aspects of the engine, and a Body Control Module may control all of the interior lighting and door functions of the vehicle. All of these modules in the vehicle are bound together using the CAN bus. Depending on the message load on the bus, typically about 20-30 nodes are connected to a single bus, but multiple buses may be used in a single vehicle. Vehicles from 2007-2015 typically used two buses, but as complexity increases, the number of buses can go to three, four, or beyond.
CAN is available on almost every vehicle produced today, largely due to industry wide utilization of the OBD-II standard.